ホワイトリストにAWS IPアドレスの範囲を登録してみた

ホワイトリストにAWS IPアドレスの範囲を登録してみた

Clock Icon2024.10.27

こんにちは。中村です。

はじめに

「ホワイトリストに登録するためにAWSの接続先IPアドレスを教えてください」と質問をいただくことがあります。
とある企業は社内ルールとして社外への通信はプロキシサーバを経由するポリシーを定めています。
事前にホワイトリストに登録したIPアドレスやドメインに対してのみ接続ができるというルールがありました。
今回、AWSを利用するにあたって社内からAWSサービスに接続するために、アウトバンド通信におけるホワイトリスト登録をする必要があったというわけです。
そんなとき、何を設定するのか考えてみます。

ホワイトリスト

結論

  • Elastic IPなどでIPアドレスを固定している場合は、そのIPアドレスを登録しましょう。
  • 特段IPアドレスを固定していない場合は、ドメインを登録を検討しましょう。

ドメインが登録不可の場合に、IPアドレスを登録か構成の変更を検討します。

AWS IPアドレスの範囲

AWSで利用されるIPアドレスの範囲は下記ドキュメントにて公開されています。

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/aws-ip-ranges.html

ip-ranges.jsonの中から、接続したいサービスおよびリージョンを基に、CIDRを取得します。

前提として、ドメインを利用してAWSに接続する場合、DNSにて名前解決を行い、IPアドレスを特定し、通信が行われます。
このIPアドレスはAWSの管理下にあり、動的に変わり、固定することができません。
そのため、IPアドレスをホワイトリストに登録したい場合は、取りうるIPアドレスリストとしてCIDRを登録する必要があります。

このCIDRを利用する上で留意点があります。

1.について、更新された場合はホワイトリストも更新する必要があります。
リリースノートは下記から確認できます。

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/aws-ip-syntax.html#aws-ip-release-notes

2.について、ホワイトリストにて通信制限を行うツールで大量のCIDRをさばく負荷に耐えられるか。管理可能か。
また、EC2のCIDRを登録する場合、登録されるCIDRには管理しているEC2のIPアドレスだけでなく、他のAWS上に存在するEC2のIPアドレスも含まれることになります。
この点でホワイトリストとして実現したいことができるのか?を考える必要があります。

3.について、ドキュメントに記載があります。

We publish the IP address ranges for services that customers commonly use to perform egress filtering. We don't publish the IP address ranges for all services.

※日本語(機会翻訳版)は読みづらかったため、原文を引用しています。

また、公開されているサービスについて、その粒度にも気をつける必要があります。
例えばEC2に関連するIPアドレスを見てみます。
一部取得してみました。

(略)
,
    {
      "ip_prefix": "54.25.20.0/24",
      "region": "us-east-1",
      "service": "EC2",
      "network_border_group": "us-east-1"
    },
    {
      "ip_prefix": "57.180.0.0/14",
      "region": "ap-northeast-1",
      "service": "EC2",
      "network_border_group": "ap-northeast-1"
    },
    {
      "ip_prefix": "64.252.80.0/24",
      "region": "sa-east-1",
      "service": "EC2",
      "network_border_group": "sa-east-1"
    },
(略)

ここで突然ですが、検証用に作成したELBの接続先IPアドレスを取得してみます。

% nslookup test-1234567890.ap-northeast-1.elb.amazonaws.com
Server:		127.0.2.2
Address:	127.0.2.2#53

Non-authoritative answer:
Name:	test-1234567890.ap-northeast-1.elb.amazonaws.com
Address: 57.180.198.55

取得した「57.180.198.55」は、先ほどEC2として検索した「"ip_prefix": "57.180.0.0/14"」に含まれています。
読者の皆さんは想定通りでしたでしょうか。
狭義のEC2インスタンスだけのIPアドレス範囲が公開されているのではなく、AWS内部的にEC2インスタンスを利用しているサービスも含めてIPアドレス範囲が提供されていると推定できます。

公開されているIPアドレス範囲は、その人の解釈によっては期待通りの範囲ではないと思います。
ご利用される時は、この点意識する必要があります。

まとめ

以上、CIDRを登録してホワイトリスト登録は技術的に可能ですが、考慮する点があります。
IPアドレス範囲を登録する前に、ドメイン登録を検討するのはいかがでしょうか。

閑話休題

さてここで、
公開されているCIDRを登録することで実際に通信ができるようになるのか?
気になりませんか?
私は気になりました。
ということで、試してみます。

今回は下記2つのパターンの検証をしてみます。

  • AWSサービスのドメイン名をホワイトリストに登録した通信
  • 特定のAWSサービスのIPアドレス範囲をホワイトリストに登録した通信

固定IPアドレスをホワイトリストに登録する通信は後者の検証を参考にしてください。
本記事では割愛します。

やってみる

前提条件

  • クライアント環境を準備する
  • クライアント環境は、接続したいAWSサービスを利用する権限があること

利用できる環境がない場合は、下記ブログ記事を参考に環境を構築してみてください。

https://dev.classmethod.jp/articles/create-ec2-playground/

検証する環境のイメージは下記です。
ホワイトリストの箇所に、ドメインやIPアドレスを登録することによって検証してみます。

ホワイトリスト2

準備

クライアント環境(EC2)に接続します。
今回の通信制限をsquidを利用して実現するため、squidをインストールします。

# yum install -y squid
# touch /etc/squid/whitelist.txt
# vi /etc/squid/squid.conf

下記設定を追加(修正)します。

acl whitelist dstdomain "/etc/squid/whitelist.txt"
http_access allow localhost whitelist
# systemctl start squid.service
# export HTTP_PROXY=http://localhost:3128
# export HTTPS_PROXY=http://localhost:3128
# export no_proxy=localhost,127.0.0.1,169.254.169.254

やってみた

接続できないことを確認

# aws s3 ls backetname

Failed to connect to proxy URL: "http://localhost:3128"

まだ何も許可設定をしていないため接続ができません。

ドメインを登録してみる

# echo "backetname.s3.ap-northeast-1.amazonaws.com" > /etc/squid/whitelist.txt
# systemctl reload squid.service
# aws s3 ls backetname
2024-08-24 00:06:32       5319 hogefile

通信できました。

CIDRを登録してみる

まずは、jsonファイルを取得します。

# echo "ip-ranges.amazonaws.com" > /etc/squid/whitelist.txt
# systemctl reload squid.service
# curl -O https://ip-ranges.amazonaws.com/ip-ranges.json

次に、東京リージョンのS3に関するCIDRをホワイトリストに登録します。

# jq -r '.prefixes[] | select(.region=="ap-northeast-1") | select(.service=="S3") | .ip_prefix' < ip-ranges.json > /etc/squid/whitelist.txt

ここで、IPアドレスを利用するため設定を一部修正します。

# vi /etc/squid/squid.conf
(修正前)acl whitelist dstdomain "/etc/squid/whitelist.txt"
(修正後)acl whitelist dst "/etc/squid/whitelist.txt"
# systemctl reload squid.service
# aws s3 ls baketname
2024-08-24 00:06:32       5319 hogefile

確かに接続できました。
ip-range.jsonから取得するサービスをEC2に変更してホワイトリストに登録した上て、S3をリストしても接続はできません。

API Gatewayに接続する時の注意

上記流れでAPI Gatewayに接続する用にIPアドレスを登録してみます。

jq -r '.prefixes[] | select(.region=="ap-northeast-1") | select(.service=="API_GATEWAY") | .ip_prefix' < ip-ranges.json > /etc/squid/whitelist.txt

実はこの設定では、接続ができません。
API Gatewayの場合は、サービス名指定で出力されるCIDRはAWSから通信される接続元IPアドレスのみを示すためです。
API Gatewayに接続したい場合は、サービスAPI_GATEWAYのCIDRは接続先IP範囲として利用できないため、サービスAMAZONを利用する必要があります。
(AMZONは複数のサービスがまとまっており広い範囲を許可することになります)

API_GATEWAY にリストされているアドレスは送信専用です。すべての IP アドレス範囲を取得する場合は、AMAZON を指定します (つまり、すべてのサブセットも AMAZON サブセットに含まれます)。ただし、一部の IP アドレス範囲は AMAZON サブセット内にしかありません (つまり、別のサブセットでは使用できません)。

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/aws-ip-syntax.html

# jq -r '.prefixes[] | select(.region=="ap-northeast-1") | select(.service=="AMAZON") | .ip_prefix' < ip-ranges.json > /etc/squid/whitelist.txt

これで技術的には接続できるようになりました。
果たして、ホワイトリストとして求めている制限ができているのかは、定められたポリシーをもとに検討ください。

さいごに

今回はホワイトリスト登録を行う際、AWS IPアドレス範囲について、確かに公開されているCIDRを登録すると接続できることが確認できました。CIDRを登録する場合は、メリット・デメリットを十分に検討ください。
なお、今回プロキシとして「squid」を利用しました。本記事で紹介している設定は検証用ですので、運用される場合は、設定内容は個別に検討ください。
本記事が、参考となれば幸いです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.